1. Field of the Invention
This invention relates to computer systems, and more particularly to computer systems including timekeeping systems.
2. Description of the Related Art
Due to their limitations, time keeping devices such as time clocks are only capable of providing estimates of the current time and/or date. Time critical functions, such as air traffic control operations and banking transaction time stamping functions, require highly accurate estimates of the current time and/or date. Other time dependent functions, such as software evaluation/rental/lease agreements or music rental agreements involving set periods of time, require less accurate estimates of the current time and/or date.
A typical personal computer (PC) includes two time keeping systems: a hardware real time clock (RTC), and a software virtual clock maintained by an operating system. The RTC typically includes a battery backup source of electrical power, and continuously maintains an estimate of the current date and time. The software virtual clock is typically synchronized to the RTC during PC power up and initialization (i.e., during operating system boot up). In many PCs, synchronization of the software virtual clock to the RTC occurs only during operating system boot up.
Unfortunately, the RTC of the typical PC is highly subject to tampering. For example, a PC user is typically free to change the current date/time maintained by the RTC of the PC at will. Further, a PC user may tamper with accessible hardware components of the RTC (e.g., an oscillator crystal) in order to make the RTC run slow, thereby potentially extending time periods of software evaluation/rental/lease agreements or music rental agreements relying on the RTC for timekeeping.
Many different time synchronization systems exist for synchronizing computer system time clocks over networks (e.g., the Internet). Examples of such network time synchronization systems include the network time protocol (NTP) and the related simple network time protocol (SNTP). Time synchronization software executed by a PC typically provides periodic time synchronization of an RTC of the PC to an external time source. The time synchronization software may also track RTC timekeeping errors and adjust programmable RTC timekeeping circuits to improve RTC timekeeping accuracy between periodic time synchronizations.
It is now possible to obtain (e.g., via the Internet) application software and other content (e.g., music) for use over a fixed period of time (e.g., on an evaluation basis, or subject to a rental or lease agreement). As techniques do not exist for verifying the accuracy and/or security of a PC timekeeping system, sophisticated software evaluation/rental/lease systems typically include with the application software either separate timekeeping software or monitoring software which detects/prevents changes to the current date/time maintained by the RTC of a PC. Like the RTC itself, timekeeping and monitoring software is vulnerable to tampering, and security issues related to software evaluation/rental/lease systems are believed to be major reasons why relatively expensive application software programs (e.g., large computer aided design programs) are generally not available for evaluation/rental/lease via the Internet.
A real time clock (RTC) of a computer system typically functions as a local source of estimates of the current time. In order to facilitate applications such as the distribution of software for evaluation/rental/lease via the Internet, it would thus be desirable to have an RTC having several highly desirable timekeeping accuracy and/or security (e.g., time clock tamper resistance) attributes. For example, more expensive application software for evaluation/rental/lease may require estimates of the current time from sources having higher levels of timekeeping accuracy and/or timekeeping security. In this case, having an RTC with a relatively high level of timekeeping accuracy and/or security may allow access to a larger set of application software for evaluation/rental/lease.
A real time clock (RTC) is described several highly desirable timekeeping dependability and timekeeping security attributes. The RTC may have several registers for storing values, at least one of which stores a value which is safeguarded. For example, a xe2x80x9cTrustQualityStatexe2x80x9d register stores a xe2x80x9cTrustQualityStatexe2x80x9d value which is dependent upon a timekeeping accuracy of the RTC. The xe2x80x9cTrustQualityStatexe2x80x9d value may also be dependent upon a timekeeping stability of the RTC, a timekeeping reliability of the RTC, and/or a timekeeping security of the RTC (e.g., a tamper resistance of the RTC). The RTC includes an access unit coupled between the xe2x80x9cTrustQualityStatexe2x80x9d register and a bus used to access the xe2x80x9cTrustQualityStatexe2x80x9d register. The access unit controls access to the xe2x80x9cTrustQualityStatexe2x80x9d register in order to safeguard the xe2x80x9cTrustQualityStatexe2x80x9d value.
The access unit is adapted for coupling to the bus. In some embodiments, the RTC may be adapted for coupling to a peripheral component interconnect (PCI) bus. For example, the RTC may be part of xe2x80x9csouthxe2x80x9d bridge logic coupled between a PCI bus and an industry standard architecture (ISA) bus. The south bridge logic may couple address, data, and/or control signals between the RTC and the PCI bus. In other embodiments, the RTC may be adapted for coupling to an ISA bus.
The access unit receives a value (e.g., the xe2x80x9cTrustQualityStatexe2x80x9d value) to be stored in a register (e.g., the xe2x80x9cTrustQualityStatexe2x80x9d register) as write data from a source via the bus. The access unit is configured to determine if the source is authorized to modify the value, and to store the value in the register only if the source is authorized to modify the value.
The register may include multiple volatile storage cells requiring electrical power to store the value. In this case, the RTC may include a battery, and the register may receive electrical power from: (i) a source external to the RTC (e.g., a computer power supply), and (ii) the battery when electrical power is not available from the external source. Alternately, the register may include multiple non-volatile storage cells which do not require electrical power to store the value.
The value stored in the register may expire a predetermined period of time after issue. In this case, the access unit may be configured to store a default value of xe2x80x9c0xe2x80x9d in the register when the predetermined period of time has elapsed. For example, the RTC may include a counter configurable to issue a signal after the predetermined period of time. When the access unit receives the value and stores the value in the resister, the access unit may configure the counter to issue the signal after the predetermined period of time. When the access unit receives the signal from the counter, the access unit may store the default value of xe2x80x9c0xe2x80x9d in the register.
The counter may require electrical power for operation. In this case, where the RTC includes a battery, the counter may receive electrical power from: (i) the source external to the RTC, and (ii) the battery when electrical power is not available from the external source.
The RTC may also include timekeeping logic coupled to receive a clock signal and configured to maintain an estimate of the current time dependent upon a frequency of the clock signal. The RTC may also include accuracy detection logic coupled to receive the clock signal and configured to issue an error signal if the frequency of the clock signal deviates from an acceptable frequency range.
A method for storing a value in a register, which may be embodied within a receiver coupled between the register and a bus used to access the register and controlling access to the register, includes the receiver receiving a read command directed to the register from a source. The read command may, for example, include the address of the register where the register is an addressable register. The receiver provides a challenge value to the source as read data in response to the first read command. The receiver uses the challenge value to calculate an expected response value. The receiver receives a first write command directed to the register and including a response value as write data. The receiver compares the response value to the expected response value. The receiver receives a second write command directed to the register and including the value to be stored in the register as write data. The receiver stores the value in the register only if the response value is equal to the expected response value. In addition, the second write command may need to be the first command received following the first write command in order for the receiver to store the value in the register.
A corresponding method for storing a value in a register, which may be embodied within the source, includes the source issuing the read command directed to the register, and receiving the challenge value as read data. The source uses the challenge value to calculate the response value. The source issues the first write command directed to the register and including the response value as write data. The source issues the second write command directed to the register and including the value to be stored in the register as write data.
The above methods for storing a value in a register may include multiple challenge-response exchanges. During each challenge-response exchange, the source issues a read command directed to the register. The receiver receives the read command and provides a challenge value as read data in response to the read command. Each challenge value is preferably different from all others. While the source receives the challenge value as read data and uses the challenge value to calculate the response value, the receiver uses the challenge value to calculate the expected response value. The source issues a write command directed to the register and including the response value as write data. The receiver receives the write command, and compares the response value to the expected response value. As multiple challenge-response exchanges are performed, each challenge-response exchange may include the receiver recording a challenge-response failure if the response value is not equal to the expected response value.
After the final challenge-response exchange, the source issues a final write command directed to the register and including the value as write data. The receiver receives the final write command, and stores the value in the register only if a challenge-response failure is not recorded in any of the challenge-response exchanges. In addition, the final write command may need to be the first command received following the write command of a final challenge-response exchange in order for the receiver to store the value in the register.
In an alternate method for storing a value in a register, which may be embodied within the receiver, the receiver receives a write command from the source. The write command is directed to the register and includes write data. A first portion of the write data is designated for conveying a password value, and wherein a second portion of the write data is designated for conveying the value to be stored in the register. The receiver compares the contents of the first portion of the write data to the password value, and stores the value in the register only if the contents of the first portion of the write data is equal to the password value. The write data may be encoded, and the method may include decoding the encoded write data.
A method for providing a value stored in a register, which may be embodied within a receiver coupled between the register and a bus used to access the register and controlling access to the register, includes the receiver receiving a first read command directed to the register from a source. The receiver provides a challenge value as read data in response to the first read command, and uses the challenge value to calculate an expected response value. The receiver receives a write command directed to the register and including a response value as write data. The receiver compares the response value to the expected response value. The receiver receives a second read command directed to the register. The receiver provides the value stored in the register as read data in response to the second read command only if the response value is equal to the expected response value. In addition, the second read command may need to be the first command received following the write command in order for the receiver to provide the value stored in the register.
A corresponding method for obtaining a value stored in a register, which may be embodied within the source, includes the source issuing the first read command, and receiving the challenge value as read data. The source uses the challenge value to calculate the response value. The source issues the write command directed to the register and including the response value as write data. The source issues the second read command directed to the register, and receives the value stored in the register as read data.
The above methods for providing and obtaining a value in a register may include multiple challenge-response exchanges. During each challenge-response exchange, the source issues a read command directed to the register. The receiver receives the read command, and provides a challenge value as read data in response to the read command. Each challenge value is preferably different from all others. While the source receives the challenge value as read data and uses the challenge value to calculate the response value, the receiver uses the challenge value to calculate the expected response value. The source issues a write command directed to the register and including the response value as write data. The receiver receives the write command, and compares the response value to the expected response value. As multiple challenge-response exchanges are performed, each challenge-response exchange may include the receiver recording a challenge-response failure if the response value is not equal to the expected response value.
After the final challenge-response exchange, the source issues a final read command directed to the register. The receiver receives the final read command, and provides the value stored in the register as read data only if a challenge-response failure is not recorded in any of the challenge-response exchanges. In addition, the final read command may need to be the first command received following the write command of a final challenge-response exchange in order for the receiver to store the value in the register.
In an alternate method for providing a value stored in a register, which may be embodied within the receiver, the receiver receives a write command from the source. The write command is directed to the register and includes write data. A first portion of the write data is designated for a password value, and a second portion of the write data is designated for a value indicative of a read request directed to the register. The receiver compares the contents of the first portion of the write data to the password value. The receiver receives a read command directed to the register. The receiver provides the value stored in the register as read data in response to the read command only if: (i) the contents of the first portion of the write data is equal to the password value, and (ii) the second portion of the write data contains the value indicative of a read request directed to the register. In addition, the read command may need to be the first command received following the write command for the receiver to provide the value stored in the register. The write data may be encoded, and the method may include decoding the encoded write data.